COMMENT ⊗   VALID 00009 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.<< PUB DECLARATIONS >>
C00017 00003	.<< DEFINITIONS AND MACROS FOR BIT TABLES >>
C00020 00004	.SEC Networks
C00028 00005	.SS Glossary of Network Terms
C00035 00006	.SS Network Devices
C00048 00007	.SS I/O modes for IMP and PUP
C00052 00008	.SS IMP and PUP MTAPEs,MTAPE UUO for IMP and PUP
C00058 00009
C00089 ENDMK
C⊗;
.<< PUB DECLARATIONS >>
.DEVICE pre;
.PUBLISH←TRUE;<< set to TRUE to get different headings for even/odd pages >>
.
.<< The following assignments are to avoid ill-formed
.   expressions when PUBbing only part of the manual. >>
.CARPAG←0;
.DSKPAG←0;
.DTAPAG←0;
.ELFPAG←0;
.IMPPAG←0;
.LPTPAG←0;
.MTAPAG←0;
.PLTPAG←0;
.PTPPAG←0;
.PTRPAG←0;
.SIXPAG←0;
.TTYPAG←0;
.TVPAG←0;
.UDPPAG←0;
.XGPPAG←0;
.DDPAG←0;
.DMPAG←0;
.DIALERPAG←0;
.IIIPAG←0;
.
.<< THESE ARE LEFT ON/OFF OVER THE WHOLE MANUSCRIPT FOR CONVENIENCE! >>
.TURN ON "{#%α"
.TURN OFF "-" << Too many minus signs would be mistaken for hyphens. >>
.
.IF THISDEVICE = "XGP" THEN START
.	FONT 5 "BASB30"		<< BOLD FONT FOR HEADINGS/TITLES >>
.	FONT 4 "FIX20"		<< SOME EXAMPLES: SMALL FIXED WIDTH FONT >>
.	FONT 3 "GACS25"		<< PREFORMATTED STUFF: FIXED WIDTH FONT >>
.	FONT 2 "BASI30"		<< ITALICS (UNDERLINED WORDS) >>
.	FONT 1 "BASL30"		<< NORMAL FONT: VARIABLE WIDTH >>
.END ELSE START << for Press version >>
.	FONT 1 "timesRoman10"	<< NORMAL FONT: VARIABLE WIDTH >>
.	FONT 2 "timesRoman10I"	<< ITALICS (UNDERLINED WORDS) >>
.	FONT 3 "SAIL8"        	<< PREFORMATTED STUFF: FIXED WIDTH FONT >>
.	FONT 4 "sail6"    	<< SOME EXAMPLES: SMALL FIXED WIDTH FONT >>
.	FONT 5 "timesRoman10B"	<< BOLD FONT FOR HEADINGS/TITLES >>
.END
.
.IF XCRIBL THEN START
.
.	!XGPLFTMAR ← 216;
.	AT "⊗∪" STUFF "∩" ⊂
%2{}STUFF{}%*{  ⊃
.AT "ffi" ⊂ IF THISFONT ≤ 2 OR THISFONT = 5 THEN "≠" ELSE "fαfαi" ⊃;
.AT "ffl" ⊂ IF THISFONT ≤ 2 OR THISFONT = 5 THEN "∞" ELSE "fαfαl" ⊃;
.AT "ff" ⊂ IF THISFONT ≤ 2 OR THISFONT = 5 THEN "≥" ELSE "fαf" ⊃;
.AT "fi" ⊂ IF THISFONT ≤ 2 OR THISFONT = 5 THEN "≡" ELSE "fαi" ⊃;
.AT "fl" ⊂ IF THISFONT ≤ 2 OR THISFONT = 5 THEN "∨" ELSE "fαl" ⊃;
.AT "--" ⊂ IF THISFONT ≤ 2 OR THISFONT = 5 THEN "¬" ELSE "-α-" ⊃;
.LN←4; RN←4; << Many tables in the manual are NARROW LN,RN; >>
.	END
.
.	ELSE START
.	AT "⊗∪" STUFF "∩" ⊂
.STU←↑"STUFF";
{STU}{  ⊃
.LN←4; RN←4;
.	END
.
.
.HLINES← IF XCRIBL THEN 55 ELSE 999;	<< NUMBER OF LINES/PAGE >>
.WCHARS← IF XCRIBL THEN 81 ELSE 80;	<< NUMBER OF CHARS/LINE >>
.PAGE FRAME HLINES HIGH WCHARS WIDE;
.IF XCRIBL THEN TITLE AREA HEADING LINES 1 TO 3 CHARS 1 TO WCHARS;
.TOP←IF XCRIBL THEN 4 ELSE 1;
.AREA TEXTER LINES TOP TO HLINES CHARS 1 TO WCHARS;
.PLACE TEXTER;

.VARIABLE SECNAME, SSNAME, SSNUMBER;
.<< COUNT PAGE TO 999; this is now done in TITLE.PUB >>
.COUNT SECTION;
.COUNT SUBSECTION IN SECTION PRINTING "!.1";
.COUNT APPENDIX;

.MACRO SEC(NAME,ABBREV,PHRASE,LABEL) ⊂
.SKIP TO COLUMN 1; IF XCRIBL AND ODD PAGE AND PAGE>1 THEN SKIPPAGE;
.	SSNAME ← SECNAME ← IF "ABBREV"≠NULL THEN "ABBREV" ELSE "NAME";
.	SSNUMBER ← (SECTION+1)&"."
.			LABEL  NEXT SECTION!;
.		BEGIN
.		CENTER
%5SECTION {!}
.		SKIP
.NAM←↑"NAME";
{NAM}%*
.		SKIP 3;
.		CAT("PHRASE","NAME");
.		SEND CONTENTS ⊂ SKIP 2;
∂4{SECTION!}∂8{NAM}→{PAGE!}{SKIP;⊃
.		END	⊃

.MACRO SS(NAME,PHRASE,LABEL) ⊂
.		SSNUMBER←SECTION!&"."&(SUBSECTION+1);
.		SSNAME←"NAME";
.		IF LINES≤9 OR ¬XCRIBL THEN SKIP TO COLUMN 1;
.		LABEL  NEXT SUBSECTION!;
.		BEGIN
.		SKIP 3
.		CAT("PHRASE","NAME");
.IF XCRIBL THEN SEND CONTENTS ⊂
∂(13){!}∂(19)NAME\∞∀∂(WCHARS-2)→{PAGE!}
. ⊃
.ELSE		SEND CONTENTS ⊂
∂(13){!}∂(19)NAME\∞ ∞.∞ →{PAGE!}
. ⊃;
.		CENTER
%5{!}##NAME%*{	SKIP;
.		END		⊃

.MACRO SSP(NAME,PHRASE,LABEL,SIDE) ⊂
.	SKIP TO COLUMN 1
.	IF "SIDE"≠NULL THEN IF XCRIBL AND NOT SIDE PAGE THEN SKIPPAGE;
.SS("NAME","PHRASE","LABEL")  ⊃


.MACRO SSG(NAME,PHRASE,LABEL) ⊂
.BEGIN "SSG"; GROUP;
.SS("NAME","PHRASE","LABEL")  ⊃


.MACRO CAT(PHRASE,NAME) ⊂IF "PHRASE"≠NULL THEN SEND INDEX ⊂}<{PAGE}≤PHRASE≥{⊃  ⊃

.MACRO REFREF(A,B)     ⊂ SEND INDEX ⊂}<⊗∪see∩ B≤A≥{⊃ ⊃
.MACRO SPECIALREF(A,B) ⊂ SEND INDEX ⊂}<⊗∪see B∩≤A≥{⊃ ⊃

.AT "⊗→" SPECIFIC "↔" GENERIC "←" ⊂
.IF "GENERIC"≠NULL THEN
.	START	SEND INDEX ⊂}<{PAGE}≤GENERIC, SPECIFIC≥{⊃; "SPECIFIC GENERIC"; END
.ELSE	START	SEND INDEX ⊂}<{PAGE}≤SPECIFIC≥{⊃; "SPECIFIC"; END ⊃

.RECURSIVE MACRO STANDARD BACK ⊂
.	IF (PUBLISH AND XCRIBL) THEN START
.		ODD HEADING(,,%5{SSNAME}    {PAGE}%*);
.		EVEN HEADING(%5{PAGE}    {SECNAME}%*,,);
.	END ELSE IF XCRIBL THEN EVERY HEADING(,,%5{SSNAME}    {PAGE}%*);
.SSNAME ← "INDEX"; SECNAME ← SSNUMBER ← NULL
.	BEGIN FILL NOJUST INDENT 0,3; PREFACE 0;
.	AREA TEXTER LINES 4 TO HLINES IN 2 COLUMNS 3 APART;
.	PORTION INDEX;
.<<	IF XCRIBL AND EVEN PAGE THEN SKIPPAGE; >>
.	PLACE TEXTER;
.	SECNAME ← "INDEX";
.	WASWORD ← WASPG ← NULL ;
.	AT "<" PGNO "≤" PHRASE "≥" ⊂
.		IF "PHRASE" ≠ WASWORD THEN START BREAK }PHRASE   PGNO{ END
.		ELSE IF "PGNO" ≠ WASPG THEN }, PGNO{ ;
.		WASPG ← "PGNO" ; WASWORD ← "PHRASE" ; ⊃
%5INDEX%1
.SKIP
.	RECEIVE "≤≥"
.	END;
.SECNAME ← SSNAME ← "CONTENTS"
.SSNUMBER ← NULL
.COUNT PAGE PRINTING "i"
.PORTION CONTENTS
.AREA TEXTER LINES 4 TO HLINES CHARS 1 TO WCHARS;
.PLACE TEXTER;
.<< FILL NOJUST CRBREAK TURN ON "←→∂\∞" >>
.NOFILL; TURN ON "←→∂\∞";
.TABS 18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75;
←%5T A B L E   O F   C O N T E N T S
.SKIP 3
SECTION→PAGE%1
.SKIP;
.RECEIVE
.IF XCRIBL THEN
.	BEGIN
.	PAGE FRAME 100 HIGH WCHARS+7 WIDE;
.	NOFILL;
.	TITLE AREA HEADING LINE 1 CHARS 1 TO WCHARS+1;
.	AREA TITLS LINE 3 IN 4 COLUMNS 0 APART;
.	AREA TEXTER LINES 4 TO 100 IN 4 COLUMNS 0 APART;
.	EVERY HEADING(,%5Bit Tables%*,)
.	PORTION BITINDEX;
.	PLACE TITLS;
.	SELECT 4;
.	TABS 5,13;
.	TURN ON "\∞";
Bit∞.\Octal∞.\Name....
.SKIP TO COLUMN 2;
Bit∞.\Octal∞.\Name....
.SKIP TO COLUMN 3;
Bit∞.\Octal∞.\Name....
.SKIP TO COLUMN 4;
Bit∞.\Octal∞.\Name....
.	PLACE TEXTER;
.	SELECT 4;
.	TABS 5,13;
.	TURN ON "\";
.	AT "`" ⊂ IF LINE≥59 THEN SKIP TO COLUMN (COLUMN+1); ⊃
.	AT "≤" PHRASE "≥" ⊂
.}PHRASE
.			  ⊃
.	RECEIVE
.SKIP
Octal values of all bits
.BN←0
.REPEAT ⊂}{BN}\{EVAL("BIT"&BN)}{BN←BN+1}
.IF BN≥36 THEN DONE ⊃
.	END;
.⊃

.MACRO APP(NAME,ABBREV,PHRASE,LABEL,SIDE) ⊂
.		IF "SIDE"≠NULL THEN IF XCRIBL AND NOT SIDE PAGE THEN SKIPPAGE;
.		SSNAME ← IF "ABBREV"≠NULL THEN "ABBREV" ELSE "NAME";
.		SSNUMBER ← NULL;
.		SECNAME ← "Appendix "&(APPENDIX+1);
.SKIP TO COLUMN 1;
.<< IF XCRIBL AND EVEN PAGE THEN SKIPPAGE; >>
.			LABEL  NEXT APPENDIX!;
.		BEGIN
.		CENTER
%5APPENDIX {!}
.		SKIP
.NAM←↑"NAME"
{NAM}%*
.		SKIP 3
.		CAT("PHRASE","NAME");
.IF XCRIBL THEN SEND CONTENTS ⊂
∂4{APPENDIX!}∂8{NAM}\∞∀∂(WCHARS-2)→{PAGE!}
. ⊃
.ELSE		SEND CONTENTS ⊂
∂4{APPENDIX!}∂8{NAM}\∞ ∞.∞ →{PAGE!}
. ⊃;
.		END	⊃

.MACRO CENT (NAME,PHRASE) ⊂IF ((LINES ≤ 9) OR ¬XCRIBL) THEN SKIP TO COLUMN 1;;
.CAT("PHRASE","NAME");
.BEGIN CENTER SKIP 3
%5NAME%*
.SKIP; END
.⊃

.MACRO CENTP (NAME,PHRASE) ⊂ SKIP TO COLUMN 1;;
.CAT("PHRASE","NAME");
.BEGIN CENTER
%5NAME%*
.SKIP; END
.⊃

.MACRO CENTG (NAME,PHRASE) ⊂
.BEGIN "CENTG"; GROUP;
.CENT("NAME","PHRASE")     ⊃

.<< Force headings to be put out on an otherwise blank page >>
.MACRO SKIPPAGE ⊂ START;}#{NEXT PAGE; END ⊃



.MACRO UUO (NAME,OPCODE,OP2,DEV,NOSKIP) ⊂
.IF XCRIBL THEN SKIP 3 ELSE IF "NOSKIP"=NULL THEN SKIP TO COLUMN 1;
.BEGIN NOFILL GROUP; TABS 17; TURN ON "\";
%5NAME%3\{IF "OPCODE"="CALLI" THEN
.	START; "[OP=047, ADR=OP2]  CALLI OP2"; CAT "NAME UUO (CALLI OP2)";
.IF XCRIBL THEN SEND NAMETABLE ⊂}<NAME≤CALLI OP2≥{PAGE}>{⊃;	END
.XTDUUO(TTYUUO,051,OPCODE,OP2,NAME)
.XTDUUO(PTYUUO,711,OPCODE,OP2,NAME)
.XTDUUO(PPIOT,702,OPCODE,OP2,NAME)
.XTDUUO(PGIOT,715,OPCODE,OP2,NAME)
.XTDUUO(INTUUO,723,OPCODE,OP2,NAME)
.XTDUUO(MAIL,710,OPCODE,OP2,NAME)
.ELSE	START; "[OP=OPCODE]"; CAT "NAME UUO (UUO OPCODE)";
.IF XCRIBL THEN
.IF "DEV"=NULL THEN SEND NAMETABLE ⊂}<NAME≤OPCODE≥{PAGE}>{⊃
.	       ELSE SEND NAMETABLE ⊂}<NAME≤OPCODE DEV≥{PAGE}>{⊃;	END
.TURN OFF; VERBATIM
--------------------------------------------------
.⊃

.MACRO XTDUUO(GROUPNAME,OPCODE,NAME,ACFIELD,SPECUUO)⊂ELSE IF "NAME"="GROUPNAME" THEN
.START; "[OP=OPCODE, AC=ACFIELD]  GROUPNAME ACFIELD,";
.	CAT "SPECUUO UUO (GROUPNAME ACFIELD,)" 
.IF XCRIBL THEN SEND NAMETABLE ⊂}<SPECUUO≤GROUPNAME ACFIELD,≥{PAGE}>{⊃;	END	⊃


.MACRO UUOX(RET) ⊂BEGIN SKIP 3; GROUP SVERBATIM
--------------------------------------------------
	MTAPE <channel number>,ADR
.IF "RET"≠NULL THEN START
	RET
.END;

.⊃

.MACRO OLDUUO (NAME,OPCODE,OP2) ⊂
.BEGIN NOFILL;TABS 17;TURN ON "\";
%5NAME%*\{IF "OPCODE"="CALLI" THEN
.	START; "[OP=047, ADR=OP2]  CALLI OP2"; CAT "NAME UUO (CALLI OP2)"; END
.ELSE	"[OP=OPCODE]";
.END
.⊃

.MACRO REPUUO (NAME,OPCODE,OP2) ⊂
.BEGIN NOFILL;TABS 17;TURN ON "\";
%5NAME%*\formerly  {IF "OPCODE"="CALLI" THEN
.   START; "[OP=047, ADR=OP2]  CALLI OP2"; CAT "NAME UUO (formerly CALLI OP2)"; END
.ELSE	"[OP=OPCODE]";
.END
.⊃

.MACRO UEND ⊂SKIP; IF LINES > 3 THEN APART; FILL; SELECT 1;⊃

.MACRO VBEGIN ⊂BEGIN SKIP 1; GROUP; SVERBATIM; NARROW 8;⊃

.MACRO VEND ⊂WIDEN; IF LINES > 3 THEN APART; FILL; SELECT 1;⊃

.MACRO SVERBATIM ⊂VERBATIM; SELECT 3; ⊃

.NBRXTDUUOS←"six" << the number of extended UUOs, which see in INTRODUCTION >>

.MACRO YON (LABEL) ⊂"page ";PAGE! LABEL⊃

.MACRO YONAPP (LABEL) ⊂"Appendix ";APPENDIX! LABEL⊃

.MACRO YONSEC (LABEL) ⊂"Section ";SECTION! LABEL⊃

.MACRO YONSS (LABEL) ⊂"Section ";SUBSECTION! LABEL⊃
.<< DEFINITIONS AND MACROS FOR BIT TABLES >>

.<< HERE IS A SAMPLE MULTIPLE-BIT TABLE ENTRY:
.     "30:35\0,,77\"			END OF COMMENT >>

.BIT0  ← "400000,,0"
.BIT1  ← "200000,,0"
.BIT2  ← "100000,,0"
.BIT3  ← "40000,,0"
.BIT4  ← "20000,,0"
.BIT5  ← "10000,,0"
.BIT6  ← "4000,,0"
.BIT7  ← "2000,,0"
.BIT8  ← "1000,,0"
.BIT9  ← "400,,0"
.BIT10 ← "200,,0"
.BIT11 ← "100,,0"
.BIT12 ← "40,,0"
.BIT13 ← "20,,0"
.BIT14 ← "10,,0"
.BIT15 ← "4,,0"
.BIT16 ← "2,,0"
.BIT17 ← "1,,0"
.BIT18 ← "0,,400000"
.BIT19 ← "0,,200000"
.BIT20 ← "0,,100000"
.BIT21 ← "0,,40000"
.BIT22 ← "0,,20000"
.BIT23 ← "0,,10000"
.BIT24 ← "0,,4000"
.BIT25 ← "0,,2000"
.BIT26 ← "0,,1000"
.BIT27 ← "0,,400"
.BIT28 ← "0,,200"
.BIT29 ← "0,,100"
.BIT30 ← "0,,40"
.BIT31 ← "0,,20"
.BIT32 ← "0,,10"
.BIT33 ← "0,,4"
.BIT34 ← "0,,2"
.BIT35 ← "0,,1"

.MACRO BITSTABLE(NM,TITLE,BFLAG)⊂BEGIN
.	NARROW LN; GROUP; TABS 8,22,32; TURN ON "\";
.	NAMING←"NM";
.	BNAMING←"BFLAG";
.	IF "NM"=NULL THEN TABLEINDENT←21 ELSE TABLEINDENT←31;
.	INDENT 0,TABLEINDENT;
.IF XCRIBL THEN BEGIN
⊗∪Bits\Octal\{IF "NM"≠NULL THEN "Name\"}TITLE∩
.TBLNAM←↑"NM"[1]&"NM"[2 TO ∞];
.IF "NM"≠NULL AND "NM"≠"NAME" AND BNAMING=NULL
.	THEN SEND BITINDEX ⊂SKIP;}`≤{TBLNAM}, p. {PAGE}≥{⊃
.END ELSE BEGIN TIT←↑"TITLE";
BITS\OCTAL\{IF "NM"≠NULL THEN "NAME\"}{TIT}
.END
.	BREAK ⊃

.MACRO EVAL(εX) ⊂ X ⊃

.MACRO B(NBR,NAME,EXTRA) ⊂"NBR\";(BVALUE←EVAL("BIT"&"NBR"));"\";
.IF NAMING≠NULL THEN START
.IF "EXTRA"="*" THEN "* ";
NAME\{
.IF "NAME"≠NULL THEN START SEND INDEX ⊂}<{PAGE}≤NAME bit ({BVALUE}--{NAMING})≥{⊃;
.   IF XCRIBL AND BNAMING=NULL THEN SEND BITINDEX ⊂}≤NBR\{BVALUE}\NAME≥{⊃;
.		     END;
.END ⊃
.SEC Networks
.<< NEWSPEAK: the following words are not used in the section, in order
.	to keep the terminology uniform:
. "Foreign" - always say "remote" for the opposite of "local".
. "Host number" - always say "address", except when defining the field
.	in an address that indicates a host within a network.
. "Socket" - always say "port" or "port number" except when talking PUP
.	or defining TCP's notion of a socket.
.>>

Networks are devices that transmit data between computers.  They are
generally much faster than terminal lines, and can therefore transfer
large amounts of data at high rates of speed while being multiplexed among
many separate connections.

In discussing networks, we distinguish between the physical network,
i.e., the hardware device, and the ⊗∪protocol∩ used to interpret the data.
.CAT "protocols, network"
It is possible for the same protocol to be used on different networks, and
for different protocols to be simultaneously used on a single network.
SAIL is connected to two physical networks, the ARPAnet and an Ethernet.

.CAT "ARPAnet"
The ⊗∪ARPAnet∩ is a network of research computers managed by the U.S.
Defense Communications Agency.  A separate computer called an Interface
.CAT "IMP (Interface Message Processor)"
Message Processor (an IMP) interfaces our system with the ARPAnet.

.CAT "Ethernet"
The ⊗∪Ethernet∩ is a local network, connecting most of the computers on
the Stanford campus.  There are actually several Ethernets, which are
.CAT "gateways, network"
linked together by gateways.  (A ⊗∪gateway∩ is a computer that is
connected to more than one network, and passes messages between the
networks as a service to hosts on different networks.  SAIL is not a
gateway, even though it is on two networks.)

Because gateways connect together many diverse physical networks, it is
desirable to have a single protocol used in common on these networks.  One
such protocol, called the ⊗∪Internet Protocol∩ (or IP), has been the only
.CAT "Internet Protocol"; CAT "IP (Internet Protocol)"
one in use on the ARPAnet since 1983, and is also supported on our
Ethernet and many other networks.  The collection of networks and
computers that are able to communicate using this protocol is called the
Internet.

.CAT "PUP (PARC Universal Protocol)"
The ⊗∪PARC Universal Protocol∩ (or PUP), developed at the Xerox Palo Alto
Research Center, is the original protocol used on the Ethernet.  It is
still used regularly, although the trend is toward replacing it with IP.

Both IP and PUP are low-level, in the sense that they specify a way to
transmit ⊗∪packets∩ of data from one computer to another, but do not
guarantee the correctness or reliable delivery of these packets.  Packets
are delivered correctly with high probability, and checksums in the
packets provide assurance that they are undamaged.  On the ARPAnet, the
IMPs do in fact guarantee correct delivery, but on the Ethernet, there is
the possibility of packets being lost or garbled.

Higher-level protocols ensure the reliability that is needed.  For the
Internet, there is the ⊗∪Transmission Control Protocol∩ (TCP), and for the
.CAT "Transmission Control Protocol"; CAT "TCP (Transmission Control Protocol)"
Ethernet when using PUP, there is the ⊗∪Byte-Stream Protocol∩ (BSP).
.CAT "Byte Stream Protocol"; CAT "BSP (Byte Stream Protocol)"

(Before 1983, a protocol called the ⊗∪Network Control Protocol∩ (NCP) was
.CAT "Network Control Protocol"; CAT "NCP (Network Control Protocol)"
used on the ARPAnet, and it assumed the reliability provided by the IMPs.
NCP is no longer used, but there are references to it in the discussion
below, since the UUOs dealing with networks originally used NCP concepts
and were kept compatible during a transition period.)

This section does not purport to document the network protocols.  To find
out more about the Internet protocols, read the documents called RFCs
(Requests For Comments), which are available in printed form or online in
the directory <RFC> at the host SRI-NIC.  For the PUP protocol, read the
XEROX report ⊗∪PUP: An Internetwork Architecture∩, by David R. Boggs,
John F. Shoch, Edward A. Taft, and Robert M. Metcalfe.  Several other
Xerox reports provide more details of the PUP protocol.

In order to make the rest of this section a little clearer, we will define
some network terms first.  However, you should still read the network
documentation to gain a complete understanding of what's going on.
Whenever conflicts in terminology arise, the IP/TCP terms will be used,
with an explanation of how PUP differs.
.SS Glossary of Network Terms

⊗∪Byte∩: The basic unit of data transmitted over a network.  Unless
otherwise specified, "byte" in this section will be taken to refer to
8-bit bytes (sometimes called "octets").  When stored in a PDP-10 word,
bytes are generally packed 4 per word, left-aligned.

⊗∪Packet∩: A sequence of bytes sent as a unit.  A packet contains some
number (possibly 0) of data bytes, together with a ⊗∪header∩ identifying
the source and destination of the data, as well as other information.
An IP packet is also called a ⊗∪datagram∩.  There may be more than one
header, corresponding to the layering of protocols.  For example, TCP
packets sent on the ARPAnet have a host-to-IMP header (=12 bytes), an
IP header (=20 or more bytes), and a TCP header (=20 or more bytes),
all preceding the data in the packet.  These headers are managed by
the system, and you generally do not need to worry about their format.

⊗∪Host∩: A computer connected to a network.  Each host is identified by an
⊗∪address∩.  (Hosts also have names, but it is the responsibility
of user programs to translate these into addresses.)  A host may have more
than one address, corresponding to different networks or protocols that it
supports.  IP addresses are =32-bit integers, consisting of one to
three bytes of ⊗∪network number∩ and one to three bytes of ⊗∪host number∩
within a network.  PUP addresses are =16-bit integers, which may be
interpreted as an 8-bit ⊗∪subnetwork number∩ and an 8-bit host number.

⊗∪Connection∩: A two-way path for data to flow from one host to another.
(Some older protocols, such as NCP, defined connections to be one-way.)
Connections are only meaningful in the context of a protocol such as TCP
or BSP.

⊗∪Port∩: An identifier used to distinguish a particular connection from
other connections in the same host.  In TCP, a port is a =16-bit integer.
In PUP, ports are called ⊗∪sockets∩ and are =32-bit integers.  Certain
ports are "well-known", and are used to implement particular services.
For example, to open a TCP Telnet connection to a remote host, you connect
to its port 27.

⊗∪Socket∩: The combination of an address and port number; i.e., the
complete identification of one end of a connection.  PUP calls sockets
⊗∪ports∩.  (Most of the time there is no need for a distinction between
ports and sockets, anyway.)

⊗∪Connection establishment∩: The process by which two hosts agree to
communicate between two sockets.  The usual case involves a program at
one host (the ⊗∪user∩) wanting to connect to a well-known port at another
host (the ⊗∪server∩).  In TCP, the user sends a packet containing the SYN
flag in its header to the server's socket; the server sends back a SYN and
each side acknowledges the other's SYN; at this point the user and server
may send data over the connection, continuing to use the same port
numbers.  In PUP, the user sends a ⊗∪Request for Connection∩ (RFC) packet
to the server's port.  The server replies with an RFC, and also supplies a
new socket number to be used for the remainder of the connection.  Most of
this detail is handled for you by the system.

⊗∪State∩: A value indicating the status of a connection.  TCP defines twelve
different states that a connection can be in.  Usually it is either ⊗∪closed∩,
in which case there is no connection, or ⊗∪established∩, in which case data
may be sent in either direction.  The other states are used when opening or
closing a connection, to indicate each host's knowledge of its own and the
other host's status.

⊗∪Allocation∩: A value which specifies the maximum amount of information
which may be transmitted on a given connection.  Each host tells the other
host how much data it is willing to receive.  A transmitting host must not
send more than the receiving host has allowed it to.  This prevents data
from coming in faster than it can be read or buffered; the allocation
reflects the buffering capability.  The system takes care of allocations,
and if your job tries to send too much, it will be made to wait until the
other host sends us sufficient allocation.

⊗∪NCP∩: Network Control Program.  This is the process within a particular
host which acts as an interface between user programs and the network.
This should not be confused with the obsolete ARPAnet protocol named NCP.

.SS Network Devices

Corresponding to each protocol there is an I/O device.  Device IMP is used
for the Internet (IP) protocols, and device PUP for the PUP protocol.  (The use
of IMP as a device name dates back to the time when the IMP was the only
network device in use; nowadays the system will choose either the ARPAnet
or the Ethernet, as appropriate, to send Internet data.)

Devices IMP and PUP are similar to any other sharable I/O device in that
they may be initialized with an INIT and released with a RELEAS, but they
are different in that one must first open a connection before one may
exchange data.  One may open and close connections liberally without
having to do more than one INIT.  The INPUT and OUTPUT UUOs are used to
read data from, and to send data over, a connection.  The CLOSE UUO may be
used to close a connection.  (The close-inhibit bits determine whether to
close it completely or to still allow only sending or only receiving of
data--see the CLOSE UUO in {YONSS CLOSEUUOS}).  To open a connection or to
get one of several special functions, the user does an MTAPE UUO with the
effective address pointing to a variable length table whose first word is
a code number.  This number determines the function of the UUO.  These
functions will be explained below, but first here are explanations of some
bits relevant to devices IMP and PUP.

.SKIP 1;

The status of a connection is contained in several places.  One such place
is a status word, containing the following bits:

.BITSTABLE(IMP connection status,Meaning of a 1); NOFILL; SKIP;
.B 1,RFCS}RFC sent.
.B 2,RFCR}RFC received.
.B 3,CLSS}Close sent.
.B 4,CLSR}Close received.
.B 11,INTINR}Interrupt by receiver.
.B 12,INTINS}Interrupt by sender.
.END
.IMPSTATUSBITS: PAGE!;

The normal state of an open connection is 300000 in the left half,
possibly with other bits on that are not mentioned above (some bits are
used internally by the system).
A connection is open if and only if both RFCR and RFCS are on.
When a connection is closed or closing, CLSS or CLSR will be on.
No more data may be transmitted or received over the connection at this
point, and the appropriate open bit (RFCR or RFCS) will go off.

These bits date back to the old NCP protocol, but are also indicative of
the status of PUP connections.  For TCP, it is better to find out the
actual connection state, although the status bits usually contain a
meaningful value.  (One thing to be careful of is that a TCP connection
that is opened and then subsequently closed will have status bits 0, not
360000,,0.)

If you get an indication that the remote host is down, and if that host
is on the ARPAnet, then the following status bits give further information
received from the IMP (if all bits are 0, no such information was received).

.BITSTABLE(,Meaning);SKIP;PREFACE 0;

10:13\360,,0\Why host is inaccessible, one of the following:
.BEGIN NOFILL; NARROW TABLEINDENT;
0: Destination IMP unreachable
1: Destination host dead (bits 14:17 give reason)
2: Destination host doesn't use 96-bit leaders
3: Communication with destination host is prohibited
The other possible codes are not used.
.END; SKIP; CONTINUE

14:17\17,,0\Why host is dead, one of the following:
.BEGIN NOFILL; NARROW TABLEINDENT;
0: Reason is unknown
1: Host took ready line down without saying why
2: Host is tardy
3: Host does not exist (to the knowledge of the NCC)
4: NCP initialization at the remote host
5: Scheduled preventative maintenance
6: Scheduled hardware work
7: Scheduled software work
10: Emergency restart
11: Power outage
12: Software breakpoint
13: Hardware failure
14: Not scheduled up
15: unused
16: unused
17: Coming up now
.END; SKIP; CONTINUE

18:29\0,,777700\When host is expected back up.  7776 means unknown,
7777 means over a week from now.  Otherwise the time (in GMT) is given
as follows:

18:20\0,,700000\day of week (0 = Monday, etc.)

21:25\0,,76000\hour

26:29\0,,1700\minutes/5

.END

The remote host may send us interrupts.  The NCP protocol defined two
kinds of interrupts--from receiver and from sender--since its connections
were one-way.  PUP has only one kind, which is an interrupt from sender,
and TCP does not use interrupts at all.  (Instead, it has an indicator
called "urgent", which is currently not treated specially by the system.)
Interrupts can be received as user interrupts or can be tested for
explicitly by MTAPE 14.  Interrupts can be sent using MTAPE 11; interrupts
generated by this UUO will not appear in the connection status words for
the user generating them.  These interrupts are often used to indicate
that output should be aborted and that the host receiving the interrupt
should scan its input data stream for one of several matching network
commands.  Note that it is not guaranteed that the network will send the
interrupt faster than the matching network command; hence user programs
should keep a count, incrementing it when a network interrupt is received
and decrementing it when the matching network command is read.  Data from
the data stream should be flushed whenever the count is greater than zero.

.SKIP 1;

More status bits occur in the I/O status word, which can be gotten
with a GETSTS UUO, or examined with a STATZ or STATO UUO, or cleared
with a SETSTS UUO.  These bits are as follows:

.BITSTABLE(IMP I/O status,Meanings of 1's in IMP I/O status word)

.B 18,IOIMPM}Improper mode.
This bit is set for TCP when, for example, you try to do output and are
not in a legal state for that.

.B 19,IODERR}Device detected error.
Almost all network errors set this bit.  You should check the other status
bits to find out what happened.

.B 20,IODTER}Device detected error.
Currently, this bit is only set for PUP connections, along with the
HDEAD bit, when the system was unable to find a route to send a packet.

.B 21,IOBKTL}Block too long.

.B 22,IODEND}End of File.
This means that you read all the input that was sent by the remote host
and that there is no more forthcoming.  With TCP, you may still send data
to the other host until you close the connection.

.B 25,HDEAD}Destination host or IMP dead.
If your connection uses the ARPAnet, this means that the last message sent
stayed in the IMP network for a certain length of time without being read
by the destination.  In this case, the IMP flushes the message and sends us
back a ⊗∪host dead∩ message.  For PUP, this bit indicates that the system
was unable to find a route to send a packet.

.B 27,RSET}Reset received from remote host.
This is set for a TCP connection when the remote host has sent us a reset,
which asks us to clear all of our information about the connection.  It is
meant to be used when there is some serious error preventing the normal
method of closing connections.  You should not try to send or receive anything
more after this happens; the connection is gone.

.B 28,TMO}Timeout occurred.
Your job was in a wait state and timed out (see MTAPE 17).
.END

.SKIP 1;

.IMPINTERRUPTS:
User interrupts can be taken on a number of conditions.  These are
described below.  See {YONSEC USRINTS} to find out
how to enable and receive interrupts.

.BITSTABLE(interrupts,Interrupt condition,NO)

.B 11,INTINR}Interrupt from remote receive side (no longer used).

.B 12,INTINS}Interrupt from remote send side.

.APART

.B 13,INTIMS}Status change.  One or more of the bits CLSS, CLSR, RFCS, RFCR
has changed, or the state of a TCP connection has changed.

.B 14,INTINP}Some new input has arrived.  The next INPUT UUO will not wait.
The INTINP interrupt is generated every time a regular data message
is received by the system.  One can test for data received and
waiting in the system with an MTAPE 10 UUO.
.END

.SS I/O modes for IMP and PUP

Generally you should use buffered I/O for both IMP and PUP.  For output,
the system will compute the number of bytes in a buffer from the byte
pointer in the buffer header, and will include this number in the headers
of the output packets.  It will also give a correct byte count in the
buffer header when you do input.  (This feature is special to devices IMP
and PUP; for other devices, the byte count is converted to a word count.)
If you use dump mode, there is no way of telling the system that the
number of bytes is not a multiple of 4.

After you INIT the device, you must change the byte size in the buffer
header to 8, as described in {YONSS BUFFERRINGS}.

Device IMP normally uses the TCP protocol, unless you give MTAPE 26 after
INITing it, to select UDP (the User Datagram Protocol).  UDP has less
overhead than TCP, but does not provide the reliable delivery and flow
control that TCP does.  Several higher-level protocols are based on UDP.
It is not possible to send arbitrary IP packets, other than those allowed
by TCP or UDP.

If you are using the PUP protocol, the I/O mode determines whether you
plan to send and receive "raw packets", or use one of the byte-stream
modes for transferring data.

To send and receive arbitrary PUP packets, you must use mode 15 (Scope
Dump Mode).  You are responsible for putting the length and packet type
into the packet header, which is contained in the first 5 words of the
pakcet.  The system will insert the source and destination addresses and socket
numbers (which you have supplied by executing MTAPE UUOs to be described
below), and compute the packet checksum.

To use the EFTP protocol, open the device PUP in mode 13 (Image Binary
Mode) or mode 16 (Dump Record Mode).  Then you can send and receive
data as normal; the system takes care of the necessary acknowledgement
and retransmission.

To use the BSP protocol, use mode 0, 1, 10, or 17.

It is not possible to change protocols while an PUP channel is open.  You
may, however, change from dump mode to buffered mode, or vice versa, with
the SETSTS UUO, as long as it does not change the PUP protocol.

.SS IMP and PUP MTAPEs,MTAPE UUO for IMP and PUP

Now on to the MTAPEs themselves.

.UUO(MTAPE,072,,"  [IMP]")
.<< figure out how to index this for PUP as well
..UUO(MTAPE,072,,"  [PUP]")
.>>
	MTAPE <channel number>,ADR

ADR:	<function number>
	<other data depending on function number>
	...
.UEND

This is the general form of the IMP and PUP MTAPE UUOs.  The function number
specified at ADR determines the meaning of the UUO.  What is expected
and/or returned in the words following ADR is also dependent on the
function number.  The various functions are explained below.
.END

Some of these functions may go into a wait state.  They will be
awakened either with their normal wakeup conditions or with some
special conditions.  Some of the special conditions that may occur are
specified by the bits in the right half of the I/O status word.  For
instance, if you are waiting for input and a reset arrives, the job
is awakened and RSET is set.  An I/O error bit (one of IODTER, IODERR,
or IODEND) will be set if the wakeup was
due to a special condition, so the normal IN and OUT UUOs will
skip if the wakeup was not due to the normal wakeup condition.

In any operation which expects the status word to be returned in
word 1 (CONNECT, LISTEN, etc), an error code may be returned
instead in the rightmost 6 bits.  These errors are as follows:

.BEGIN NARROW LN,RN; INDENT 0,16; TABS 9,17; TURN ON "\"; GROUP; PREFACE 0; SKIP;
⊗∪Code\Name\Error∩
.SKIP;
  1\SIU\Socket in use.  There is already a connection on the specified
local socket number.

  2\CCS\Can't change socket numbers.  This means a remote socket
number has already been set and an RFC received for this local
socket number.  You can't change the socket number because the
remote host already knows what it is.

  3\SYS\Horrible system error.  Can't happen.  If it does, find a wizard.

  4\NLA\No link available.  System table capacity exceeded.

  5\ILB\Illegal byte size.  You attempted to establish a connection with
an improper byte size.

  6\IDD\IMP dead.  Our NCP is not running, probably
because the IMP or the ARPAnet is dead.  If you get this, see a wizard.

  7\\This error code is no longer in use.

 10\STT\State error.  You tried to do something illegal in the current
connection state.

 11\CGT\Can't get there from here.  The system is unable to find a
way to send packets to the remote host.

 12\NES\Not enough internal buffer space.  The system has run out of
buffers to hold packet data.  It may get some back if you are willing
to wait.

 13\HST\Illegal host address.

 14\DU0\Destination net unreachable.  A gateway told us that the
network in your remote address is unreachable.

 15\DU1\Destination host unreachable.  A gateway told us that the
host in your remote address is unreachable.

 16\DU2\Destination protocol unreachable.  The remote host told us that
it doesn't accept the protocol you tried to use.

 17\DU3\Destination port unreachable.  The remote host told us that 
it doesn't accept the port number you tried to use.

 20\DU4\Fragmentation needed and DF set.  A gateway needed to fragment an
IP packet, but we told it that it couldn't.  (Find a wizard if you get this.)

 21\DU5\Source route failed.  This shouldn't happen; find a wizard if it does.

 22\DUX\Destination unreachable: unknown code.  The remote host or a gateway
sent us a control message that we can't interpret.  Find a wizard.

.END

.SKIP 2
Here are the various IMP and PUP MTAPE functions available.  In all cases,
"the connection" refers to whatever connection is open on the I/O
channel for which the UUO is given.

.UUOX
ADR:	0	;CONNECT
ADR+1:	<status bits returned here>
ADR+2:	<local port number, 16 bits for TCP, 32 bits for PUP, right-justified>
ADR+3:	<wait flag: non-zero for wait for connection>
ADR+4:	<byte size>
ADR+5:	<remote port number>
ADR+6:	<remote address, 32 bits for TCP, 16 bits for PUP, right-justified>
.UEND

.CAT CONNECT to port
A TCP or PUP connection is opened to the host whose address is in word 6
with the local port number taken from word 2 and the remote port number
taken from word 5.  If word 2 is -1, a free port number will be assigned
(see MTAPE 21).  If word 3 is non-zero, the user program goes into RFC
wait until timed out (see MTAPE 17) or until the connection is
established.  (For PUP, this MTAPE causes sending of a request packet only
in BSP mode; for other PUP modes the UUO will return immediately.)

The byte size should always be 8.  The byte-size word is left over from NCP,
when different byte sizes were allowed.
.END

.UUOX
ADR:	1	;LISTEN
ADR+1:	<status bits returned here>
ADR+2:	<local port number>
ADR+3:	<wait flag: non-zero for wait; local address returned here>
ADR+4:	<byte size if sending, else byte size returned here>
ADR+5:	<remote port number returned here>
ADR+6:	<remote address returned here>
.UEND

.CAT LISTEN for connect to port
This function is used to listen for a connection request from a remote
host to a specific port number here, and to accept that connection.
If word 2 is -1, a free port number will be assigned (see MTAPE 21);
this is not especially useful.
If word 3 is non-zero, this UUO will wait for the connection to be made.
If zero, the UUO will return immediately, but the system will accept
the next connection made to the specified port for you.

The remote port number to which you get connected is returned in
word 5; -1 is returned if no connection has been made (wait flag off).
The remote address is returned in word 6.

The local address (for TCP connections) is returned in word 3.  This
is useful if we have more than one Internet address and you need to know
which one is being used.
.END

.UUOX
ADR:	2	;GET STATUS
ADR+1:	<status bits for connection returned here>
ADR+2:	<status bits for connection returned here>
.UEND

This function returns the status bits for the connection.  In NCP,
separate bits for the send and receive side were given; nowadays the two
words are the same.  These bits are explained on {YON IMPSTATUSBITS}.  If
no connection is open, zero is returned.
.END

.UUOX
ADR:	3	;TERMINATE CONNECTION
ADR+1:	<status bits returned here>
ADR+2:	<local port number>
ADR+3:	<wait flag: non-zero to wait for close>
.UEND

This closes the TCP or PUP connection.  Specifying the local port number
is a relic from NCP; it should be the port number for the connection or
zero, which is taken to mean that port.

If word 3 is non-zero, the job is placed in CLS wait until both hosts have
closed the connection, or the CLS timeout occurs (signified by TMO being
on in the I/O status word).

The CLOSE UUO may also be used to close one or both of the send and receive
connections (the close-inhibit bits determine which sides are closed--see
the CLOSE UUO in {YONSS CLOSEUUOS}).
.END

.UUOX
ADR:	4	;WAIT FOR CONNECTION COMPLETION
ADR+1:	<status bits returned here>
ADR+2:	<port number>
.UEND

This is meaningful only if a CONNECT or LISTEN was given without
waiting (word 3 = 0).  In this case, the job is put into RFC wait
until a connection is opened or a timeout occurs.

The port number must be the same as in the CONNECT or LISTEN, or zero.
.END

.UUOX
ADR:	5	;EXTENDED STATUS (IMP only)
ADR+1:	<number of words desired>
ADR+2:	<I/O status> (same value as returned by GETSTS UUO)
ADR+3:	<status bits> (the value returned in ADR+1 by many MTAPEs)
ADR+4:	<connection state>
ADR+5:	<local address>
ADR+6:	<local port number>
ADR+7:	<remote address>
ADR+10:	<remote port number>
ADR+11:	<network address> (gateway, if different from remote address)
ADR+12:	<IP protocol>
ADR+13:	<input window>					(TCP)
ADR+14:	<output window>					(TCP)
ADR+15:	<current retranmission timeout time>		(TCP)
ADR+16:	<next sequence number to be received>		(TCP)
ADR+17:	<next sequence number to be sent>		(TCP)
ADR+20:	<next sent sequence number to be acknowledged>	(TCP)
.UEND

This returns a number of words of information about the current
connection.  Word 1 contains the number, ⊗∪n∩, of words desired (currently
=15 is the maximum possible), and the system fills in the ⊗∪n∩ words
starting with word 2.  If more values are ever added to the table, this
will allow old programs to run without error.  Those entries marked (TCP)
have meaning only if the connection is a TCP connection.

The IP protocol number returned in word 12 is 6 for TCP, =17 for UDP.
.END

.UUOX
ADR:	5	;GET MONITOR TABLES (PUP only)
ADR+1:	<number of words of tables desired>
ADR+2:	<address of place to put tables>
.UEND

This copies various values from the monitor into your core image.  The
values currently returned (mostly pointers to tables in the system) are:

.BEGIN SVERBATIM;SKIP
word 0:	<unused>
word 1:	<unused>
word 2:	<unused>
word 3:	0,,<number of active links>
word 4:	<table of remote addresses>,,<table of DDB addresses>
word 5:	<table of local sockets>,,<table of remote sockets>
word 6:	0,,<table of connection status bits>
.END;SKIP;CONTINUE;

This MTAPE is based on MTAPE 5 for device IMP under the NCP protocol, and
no one really uses it.  (See {YONAPP MONITORLOCS} for the addresses of low
core monitor pointers to these tables, and similar pointers for IMP
information.)
.END

.UUOX
ADR:	6	;WAKEUP MAIN PROCESS
.UEND

This function is valid only when given at interrupt level.  It will wake
up the main process if it is in any wait state due to the IMP or PUP
connection.  It also sets TMO in the I/O status bits.
.END

.UUOX
ADR:	7	;GET ADDRESS AND PORT NUMBERS
ADR+1:	<status bits returned here>
ADR+2:	<local port number returned here>
ADR+3:	<local address returned here>
ADR+4:	<byte size returned here>
ADR+5:	<remote port number returned here>
ADR+6:	<remote address returned here>
.UEND

This returns the local and remote addresses and port numbers associated
with the connection.  Its main use is to get this information after doing
a non-waiting CONNECT or LISTEN.
.END

.UUOX
ADR:	10	;SKIP IF ANY INPUT PRESENT
.UEND

This function skips if there is input waiting that has not yet been
transferred to the user's buffers.  Otherwise the direct return is taken.
.END

.UUOX
ADR:	11	;SEND INTERRUPT
ADR+1:	<status bits returned here>
ADR+2:	<local port number>
.UEND

This function sends an interrupt to the remote host.  The TCP protocol does not
contain this operation, so it is only legal for PUP connections.  (TCP has a
related concept called the "urgent" signal, which we don't implement.)
.END

.UUOX
ADR:	12	;TURN NETWORK ON
.UEND

This function attempts to restart the network if it is not working.
It requires the UPG privilege (for device IMP) or the ACW privilege
(for device PUP) to be enabled.
.END

.UUOX
ADR:	13	;TURN NETWORK OFF
.UEND

This function turns the network off.  It is only applicable to device IMP.
.END

.UUOX
ADR:	14	;TEST AND CLEAR INTERRUPTS
ADR+1:	<-1 returned here if any send side interrupts>
ADR+2:	<-1 returned here if any receive side interrupts>
.UEND

This UUO tells you if you have received an interrupt from the
remote host.  It also clears the interrupt condition.  "Receive side"
interrupts will never happen; they are left over from NCP.  Device IMP
does not generate interrupts, but PUP may do so.  A minus one is returned
if an interrupt has been received, and a zero is returned if no interrupt
has been received.  When an interrupt arrives, the INTINS bit is set in
the status word for that connection, and if you are enabled for that
interrupt condition, a user interrupt is generated.
.END

.UUOX
ADR:	15	;ALLOCATE
ADR+1:	<function code: 0 for as specified, 1 for system max,
	  2 for system min, and 3 for system default values>
ADR+2:	<number of bits of allocation (for function 0)>
ADR+3:	<number of messages of allocation (for function 0)>
.UEND

This changes the allocation we have given the remote host.  (This UUO has
not been implemented for TCP and will be treated as a no-op.)  If this UUO
is not given, the system default value is used.  For TCP, the default
allocation is =4320 bytes (=34560 bits).  For PUP, the default is =2048
bytes (=16384 bits), the system maximum is =4096 bytes, and the system
minimum is 8 bytes.  Allocation is in two dimensions; you can allocate
both the number of bits and the number of messages the remote host may
send.

If the function code (ADR+1) is 0, the new allocation is taken from ADR+2
and ADR+3, clipped to fit within the system maximum and minimum, and set
accordingly.  Notice that if the connection is not yet open, this UUO does
not actually cause the allocation to happen; it just sets the values that
will be given.

There are several advantages to changing the allocation.  Using larger
allocations is much more efficient and much faster, but it also means
that unless you are handling network interrupts and output resets, it
will take a long time before an output abort operation takes effect,
since that much more data is being buffered.  Having a smaller allocation
means faster response to abort operations at the expense of much less
efficiency and speed.  File transfer programs should always use the system
maximum allocation; a TELNET-type user program may or may not want to use it
depending upon whether or not it processes output aborts using the network
interrupt mechanism.  TELNET server programs probably want system maximum
message allocation and a smaller bit allocation.
.END

.UUOX
ADR:	16	;GET ALLOCATIONS
ADR+1:	<number of bits we have allocated remote host>
ADR+2:	<number of messages we have allocated remote host>
ADR+3:	<number of bits remote host has left>
ADR+4:	<number of messages remote host has left>
ADR+5:	<number of bits in free storage>
ADR+6:	<number of messages in free storage>
ADR+7:	<number of bits remote host has allocated us>
ADR+10:	<number of messages remote host has allocated us>
.UEND

Function 16 returns the above allocation values.
.END

.UUOX
ADR:	17	;SET TIMEOUTS
ADR+1:	<word of 6-bit bytes: number of 2-second units
	  for timeouts on CLS, RFNM, ALLOC, RFC, INP;
	  0 means never timeout.>
.UEND

A job can enter a wait state waiting for any one of five different kinds
of events to occur: CLS (completion of the close of a connection), RFNM
(no longer meaningful; was part of NCP), ALLOC (allocation from the remote
host, needed to send data), RFC (completion of the opening of a
connection), or INP (input data from a remote host).  In each of these
cases, a timeout may be set.  IMP MTAPE function 17 takes 6-bit fields
from word 1 for five timeout values:  CLS timeout is in bits 0:5
(770000,,0 bits), RFNM in bits 6:11 (7700,,0 bits), ALLOC in bits 12:17
(77,,0 bits), RFC in bits 18:23 (0,,770000 bits), and INP in bits 24:29
(0,,7700 bits).  The value in each field is the number of 2-second units
of timeout duration.  The maximum timeout duration is thus =126 (2*=63)
seconds.  Zero in any field means never time out waiting for that
condition (i.e., wait forever for that condition).  Bits 30:35 (0,,77
bits) are not currently used.

When a RFNM, ALLOC or INP timeout occurs, one or more I/O status error bits
are set (which will cause an IN or OUT UUO to take the error return).
When an RFC or CLS timeout occurs, the UUO in
progress just goes on as if it had never tried to wait.
When any of the five timeouts occurs, the timeout bit (TMO) is set in the
connection status word.

The system default timeout values are 6 seconds for CLS,
40 seconds for RFNM, and no timeout for ALLOC, RFC, and INP.

When establishing a connection you will want to set timeouts for RFC
and INP in case the other host does not have anything listening on that port
and never bothers to refuse the connection.  Otherwise the connection attempt
will hang forever.  The timeout should be picked to be short enough to be
useful but reasonably long to allow for a loaded system at the other end.
.END

.UUOX
ADR:	20	;GET TIMEOUTS
ADR+1:	<current timeout word returned here>
.UEND

Function 20 returns the current timeout word as defined above in function 17.
.END

.UUOX
ADR:	21	;GENSYM A PORT
ADR+1:	<port number returned here>
.UEND

Function 21 finds the number of a port not currently in use and returns it.
The returned port and the next 7 consecutive numbers are all reserved and
may be freely used to establish new connections.

.END

.UUOX
ADR:	22	;ABORT CONNECTION (IMP only)
ADR+1:	<status bits returned here>
.UEND

Function 22 sends a TCP RESET to the remote host, causing both sides to
immediately drop the connection.  This should only used in emergencies,
when the ordinary connection close does not work.

.UUOX
ADR:	23	;SEND HOST DOWN STATUS MESSAGE (IMP only)
ADR+1:	<host down code>
.UEND

Function 23 sends a code to the IMP telling it we are about to go down.
Ordinary programs should never use this UUO.  It requires the UPG privilege
to be enabled.  Bits in the code are interpreted as follows:

.BITSTABLE(,Meaning);SKIP;PREFACE 0;

0:13\777760,,0\unused

14:17\17,,0\Reason for going down

18:23\0,,770000\unused

24:35\0,,7777\Time expected back up
.END

They have the same meaning as error codes returned from the IMP,
described in the discussion of status bits above.

.UUOX
ADR:	25	;SELECT PUSH HANDLING (IMP only)
ADR+1:	<function code: 0 to PUSH always, 1 to PUSH on next output,
	  2 to PUSH only on connection close>
.UEND

Function 25 for TCP connections tells the system when to set the PUSH
bit in outgoing packets.  If PUSH is set, the remote host will try to
deliver the data to the receiving process as soon as possible.  Word 1
is 0 (the default) to set PUSH on the last packet used for each output
buffer; 1 to set PUSH on the last packet of the next output buffer but
not again until closing the connection (or executing this MTAPE again);
or 2 to not set PUSH until closing the connection.
.END

.UUOX
ADR:	25	;SEND A MARK (PUP only)
ADR+1:	<status bits returned here>
ADR+2:	<mark code>
.UEND

Function 25 for PUP/BSP connections sends a Mark packet, with the
one-byte mark code contained in word 2 (right-aligned).  This MTAPE
takes a direct return if the connection is in an improper state, or
skips if the mark was sent successfully.
.END

.UUOX
ADR:	26	;SET UDP PARAMETERS (IMP only)
ADR+1:	<status bits returned>
ADR+2:	<local port number>
ADR+3:	<unused>
ADR+4:	<unused>
ADR+5:	<remote port number>
ADR+6:	<remote address>
.UEND

Function 26 for device IMP tells the system to use UDP, the ⊗∪User Datagram
Protocol∩, instead of TCP, and gives the address and port numbers associated
with this I/O channel.

It is not possible (or meaningful) to intermix UDP and TCP operations on
the same IMP channel.  However, a closed IMP channel may be reused for
either TCP or UDP without releasing it.

This MTAPE first discards any UDP packets waiting to be read, and then
sets the host and UDP port numbers for the I/O channel.  Word 2 may be -1
if you want the system to generate a new port number; in that case the
number generated will be returned there.  The remote host and port may be
0 (to match any host and/or port) if you read a packet before you attempt
to write one.

An error code will be returned in word 1 if you are not in the right state
to perform this operation (i.e., you have an open TCP connection).

While there is no "connection" as in TCP, you still have to tell the
system the remote host and port number and the local port number
associated with the I/O channel.  They must all be non-zero if the first
I/O operation is an output (the local port may be -1 to ask the system to
assign a free port), but the remote host and port may be 0 when doing
input, to ask for packets from any remote host and/or port.  If this is
done, then when a packet is read the remote host and port for the
I/O channel will
automatically be set to the values in that packet, so that subsequent
input and output will use those values, unless they are reset to 0.

After a successful return, IN and OUT UUOs are used to read and send UDP
packets.  Each IN or OUT always corresponds to a single packet.  On input,
if the packet is longer than the user buffer, the UUO will fail with the
IOBKTL bit set in the I/O status word.  On output, the data must fit in a
single buffer.  If you try to send more than the system can put in a
packet, output will fail with IOBKTL set in the I/O status word.  Either
buffered or dump mode may be used, but buffered mode is recommended since
there is no way to specify an exact byte count in dump mode.

When a packet arrives that matches your connection, it will be discarded
if there is a previous packet waiting that you have not read yet.  This
should not get in the way of most applications, since they typically
involve an exchange of single packets, or acknowledgement of each packet
before the next is sent.

Most of the other IMP MTAPEs are not meaningful for UDP, but the following
may be used:

.BEGIN TURN ON "\"; NARROW LN; TABS 7; NOFILL;

⊗∪Function\Description∩

2\Get status bits
5\Extended status
6\Wakeup main process from interrupt level
7\Get local port, remote port, and remote host
10\Skip if input waiting
17\Set timeouts
20\Get timeouts
.END

The only timeout value that is used in UDP is the input timeout.
.END

.UUOX
ADR:	26	;RECEIVE A MARK (PUP only)
ADR+1:	<status bits returned here>
ADR+2:	<mark code returned here>
.UEND

Function 26 for PUP/BSP or EFTP connections returns the code in the last
mark or EFTP abort packet received.  If the connection is in an improper
state, or the last packet was not a mark or EFTP abort, it takes the
direct return; otherwise it returns the 8-bit mark code or 16-bit EFTP
abort code in word 2 and takes the skip return.
.END

.UUOX
ADR:	27	;GET ROUTING TABLE (PUP only)
ADR+1:	IOWD LEN,BUFFER
ADR+2:	<actual length returned here>
.UEND

Function 27 for device PUP returns the system's routing table, which shows
what Ethernet subnetworks are accessible and what gateways are used to
reach them.  Word 1 contains the length and address of the buffer in the
user program into which the table will be copied.  The actual length of
the system's table is returned in word 2; if this is more than the length
of the buffer then the extra words are not copied to your program.
.END

.UUOX
ADR:	30	;SET ROUTING TABLE (PUP only)
ADR+1:	IOWD LEN,BUFFER
.UEND

Function 30 for device PUP replaces the system's routing table.  You must
have the ACW privilege enabled to do this MTAPE.  If you are not privileged,
the direct return is taken; otherwise the MTAPE skips to indicate success.
.END